I like option 2 -- it exactly covers what we want to do while accomodating the existence of older drafts.

We should still be able to disallow fragments (even empty ones), while still allowing the use of the draft7 and earlier schemas in a new implementation, even with a restriction in the metaschema itself (e.g. with the pattern keyword) -- as a schema should not be getting validated against a metaschema other than the one specified in the $schema keyword.

We would just need to point out the exception for older schemas, so the implementation doesn't reject the use of an empty fragment before considering if an older draft's semantics should apply.

By allowing these, are we saying that all historical schemas are valid v1 schemas that just use different dialects, e.g. a draft 6 dialect? Otherwise it seems to me that those schemas would be valid under their own spec versions but not v1, and thus we don't need to state the exception.

This is the change I worked up:

The value of this keyword MUST be an
[absolute IRI](https://www.rfc-editor.org/info/rfc3987) (without a fragment). This
IRI MUST be normalized. Exceptions exist for previous versions of this
specification and meta-schemas based on those version, which have fragments
defined in their `$schema` values, namely:

- `http://json-schema.org/draft-03/schema#`
- `http://json-schema.org/draft-04/schema#`
- `http://json-schema.org/draft-06/schema#`
- `http://json-schema.org/draft-07/schema#`

But it seems odd to explicitly reference older versions like this.